Celestin Apprentice 5/Apprentice-Release5.iso/Information/CSMP Digest/volume 1/csmp-v1-150.txt

Text File | 1992-12-31 | 43.5 KB | 1,148 lines | [TEXT/R*ch]

C.S.M.P. Digest             Sun, 02 Aug 92       Volume 1 : Issue 150

Today's Topics:

    Emulating TrueType
    Sending Apple events to the Finder.
    Light-weight processes in a Mac program
    need help writing a screensaver
    Offscreen PixMaps
    Apple Event problem
    Getting the text from a TERec



The Comp.Sys.Mac.Programmer Digest is moderated by Michael A. Kelly.

The digest is a collection of article threads from the internet newsgroup
comp.sys.mac.programmer.  It is designed for people who read c.s.m.p. semi-
regularly and want an archive of the discussions.  If you don't know what a
newsgroup is, you probably don't have access to it.  Ask your systems
administrator(s) for details.  (This means you can't post questions to the
digest.)

Each issue of the digest contains one or more sets of articles (called
threads), with each set corresponding to a 'discussion' of a particular
subject.  The articles are not edited; all articles included in this digest
are in their original posted form (as received by our news server at
cs.uoregon.edu).  Article threads are not added to the digest until the last
article added to the thread is at least one month old (this is to ensure that
the thread is dead before adding it to the digest).  Article threads that
consist of only one message are generally not included in the digest.

The entire digest is available for anonymous ftp from ftp.cs.uoregon.edu
[128.223.8.8] in the directory /pub/mac/csmp-digest.  The most recent issues
are available from sumex-aim.stanford.edu [36.44.0.6] in the directory
/info-mac/digest/csmp.  If you don't have ftp capability, the sumex archive
has a mail server; send a message with the text '$MACarch help' (no quotes)
to [e-mail] for more information.

The digest is also available via email.  Just send a note saying that you
want to be on the digest mailing list to [e-mail], and you will
automatically receive each new issue as it is created.  Sorry, back issues
are not available through the mailing list.

Send administrative mail to [e-mail].


-------------------------------------------------------

From: [e-mail] (David Phillip Oster)
Subject: Emulating TrueType
Organization: Whole Earth 'Lectronic Link
Date: Wed, 10 Jun 1992 06:59:32 GMT

I've got the code from "develop" magazine issue 9, for extracting the bezier
curves from a truetype font and drawing them on the screen, or in a PICT with
the accompanying postscript. What I want to know is How does true type know
how to fill the outlines. For example, you have to two concentric circles
that are the curves that define a letter "o". How does TrueType know to
fill the outer circle, but not fill the inner one. This is probably covered
in detail in the APDA document that details the TrueType font format, but I'd
like an answer sooner than that document will reach me. I want to extrude the
letters into 3-d, then make them "dance" in 3-space.

+++++++++++++++++++++++++++

From: [e-mail] (David Phillip Oster)
Organization: Whole Earth 'Lectronic Link
Date: Sat, 13 Jun 1992 03:51:21 GMT

The following people responded to my question about deriving surfaces
from True Type spline definitions:
[e-mail]    (Jonathan)
[e-mail]        (Larry Rosenstein)
[e-mail] (Tom Dowdy)
[e-mail]      (Tim Dierks, software saboteur (MacDTS))

all but Tom  referred me to the "winding" rasterizing algorithm in the
Adobe Postscript red book. This is an algorithm for determining what
pixels to turn on in a raster, essentially doing a flood fill or a
paint pot of the splines. Unfortunately, I need somethng like a minimal
mesh of triangles in three space, so the rasterization algorithm is
just about useless. Considering each scan line as a rectangle 1 pixel
tall would sort of work, but it would be hopelessly inefficient, and
wouldn't take advantage of the original spline data as the viewpoint
moved closer and further away from the plane of the letter.

Also, all of the people who wrote me assumed that the outsides of
letters were drawn clockwise, and the outlines of interior "holes" were
drawn counterclockwise. Tim, who should know, assured me that this was
the case.

Watching the "Curves in QuickDraw" program draw, I am not sure that
this is the case. (All though it is pretty easy to fix this, using the
intersections of bound boxes to drive a heuristic.) It is certainly the
case that sometimes the holes are drawn before the outsides.

If you are interested, here is Jonathon's description of the
rasterization process:


>Pure conjecture on my part, but PostScript determines what regions to
>fill by crossing windings, and since TrueType is just an enhancement to
>PS I'd assume it works the same way. To determine windings, draw an
>imaginary line across your object at any point, and increment the wind
>count when you cross a line drawn clockwise, and decrement your count
>when the line is draw counterclockwise. A positive wind count  means
>you are in a fill region. That is, if the outer circle is drawn
>clockwise and the inner circle is drawn counterclockwise, than a
>horizontal line across the 'o' would start with zero windings, cross
>the first line and have one windings (so now we're filling) cross the
>second line (so now we're through filling) cross the second line again
>(so we're filling once more) and finally cross the first line a second
>time (and we're back to our original fill status). [0 1 0 1 0] Note
>that it is the change in the direction of the line crossed that is
>important. That is, if the inner circle was drawn clockwise as well,
>the total "winding" value would still be positive when you crossed the
>second line [0 1 2 1 0] and you'd end up with a filled circle instead
>of an 'o'. Or if the outer circle was wound in the opposite direction,
>you would go [0 -1 -2 -1 0] and you would end up with two concentric
>circles instead of an 'o' (since you are never positive and hence never
>fill.)  Pick up an introductory postscript book (the adobe 'cookbooks'
>are excellent) for better explanations. (or browse through the stuff
>thats available for ftp on adboe.com)

Actually I'm trying to use a library that uses NURBS to describe
surfaces and lets you pass it further NURBS curves to defines holes
punched in the surfaces. Anybody got a good intro reference to NURBS?

I sort of know what I'm doing on this score. I wrote an article some
years ago for MacTutor on how to draw the famous "teapot" on the mac
using Graf3d.  It is composed of the 3-D analog of the quadratic planar
bezier splines that make up true type characters. You haven't read it
because MacTutor lost it before accepting it and I never got around to
resubmitting it. Since I got tired of people distributing my trivial
demo programs without the accompanying source code that was the
_raison_d'etre_, I added a "Decompile" command to the menu which faked
the THINK C "compiling' dialog running backwards, and created a mess of
source files in the current directory, and also a THINK C version of
the Graf3D library.

The current issue of the "born-again" MacTutor has some useful demo
programs for 3-D animation, and an advertorial for a 3-D shaded surface
package for $250.00 (source included.)

If anyone wants a copy of the 3-D teapot source code and article, mail
$15.00 to
Mosaic Codes
Suite 2036
2140 Shattuck Ave
Berkeley, CA 94704
with a note saying "I want Teapot" and I'll send yoy a Mac floppy of
the whole thing.

+++++++++++++++++++++++++++

From: [e-mail] (Sean Parent)
Date: 25 Jun 92 16:59:05 GMT
Organization: Apple Computer, Inc.

In article <[e-mail]> [e-mail]
(David Phillip Oster) writes:
> If you are interested, here is Jonathon's description of the
> rasterization process:
>
>
> >Pure conjecture on my part, but PostScript determines what regions to
> >fill by crossing windings, and since TrueType is just an enhancement to
> >PS I'd assume it works the same way.

TrueType is not "just an enhancement to PS." It is a VERY different
mechanism for rendering fonts. By convension TrueType fonts are drawn so
that they can be filled using a winding number algorithm as described but
the TrueType engine uses an xor algorithm when it fills. This is a simpler
algorithm where the state of the fill toggles as you cross an edge.

- ----------------------------------------------------------------------
Sean Parent
"Quality unattainable in a reasonable amount of time."

---------------------------

From: [e-mail] (Levent Mollamustafaoglu)
Subject: Sending Apple events to the Finder.
Date: 12 Jun 92 06:41:41 GMT
Organization: Aiken Computation Lab, Harvard University

How can I send Apple events to the Finder itself, such as "Open
Selection"? Inside Mac VI is not very clear about this. Normally
for other applications I can determine the target address by using
AECreateDesc and the application signature, then I can use the
descriptor record in AECreateAppleEvent. But I'm confused about
what to do when the target is the Finder.

Any help from AE gurus is very much appreciated.


===========================================================================
Dr. Levent Mollamustafaoglu       Harvard University
[e-mail]    [e-mail]
===========================================================================

+++++++++++++++++++++++++++

From: [e-mail] (Jack Littleton)
Date: 12 Jun 92 17:34:09 GMT
Organization: Apple Computer, Inc.

In article <[e-mail]>, [e-mail] (Levent Mollamustafaoglu) writes:
>
> How can I send Apple events to the Finder itself, such as "Open
> Selection"? Inside Mac VI is not very clear about this. Normally
> for other applications I can determine the target address by using
> AECreateDesc and the application signature, then I can use the
> descriptor record in AECreateAppleEvent. But I'm confused about
> what to do when the target is the Finder.

There are several things you can do.  You can still use the finder's
signature, or you can use the process manager's GetNextProcess routine to
loop through all processes until you find the Finder's process number, and
use that for the address descriptor.

How to loop through the open processes is shown in Inside Mac VI, page 29-11.
Once you have the ProcessSerialNumber for the Finder, you don't need to do
the loop anymore.  That is, unless the Finder quits and relaunches (for
whatever reason), and thus gets a new ProcessSerialNumber.  If the Finder
does get a new serial number, AESend will return -903, and that's your que
to look for a new ProcessSerialNumber (do the loop thing again).

- --
Jack Littleton
Developer Tools Engineering Group
Apple Computer, Inc.

+++++++++++++++++++++++++++

From: [e-mail] (Paul Wenker)
Date: 26 Jun 92 17:50:16 GMT
Organization: Apple Computer Inc., Cupertino, CA

In article <[e-mail]> [e-mail] (Jon Pugh) writes:
>In article <[e-mail]>, [e-mail] (Levent Mollamustafaoglu) writes:
>>
>> How can I send Apple events to the Finder itself, such as "Open
>> Selection"? Inside Mac VI is not very clear about this. Normally
>> for other applications I can determine the target address by using
>> AECreateDesc and the application signature, then I can use the
>> descriptor record in AECreateAppleEvent. But I'm confused about
>> what to do when the target is the Finder.
>
>ThatUs the way to do it.
>
>    kFinderSignature            = 'MACS';
>
>    aSig := kFinderSignature;
>    err := AECreateDesc(typeApplSignature, @aSig, 4, finderAddress);
>
>Jon
>kAERegistrar


Here are some things to keep in mind when sending events to the Finder.

1) Be sure you can handle the case where the Finder isn't running.  There
are cases now (and there will be more in the future) where the Finder gets
replaced by another shell program.

2) If you want to send an event to the current shell program, as opposed
to the Finder specifically, you can loop through the existing
processes looking for a process of type 'FNDR' and then use the
ProcessSerialNumber of that process as your destination address.

3) If you send an event to the current shell program, be sure you handle
cases where that program doesn't support some or all of the Finder's events.

4) Also, be aware that the current shell program and the Finder may both
be running (i.e. there are two processes of type 'FNDR' running).  It's
unlikely that any replacement shell program could do everything that the
Finder does, so there will probably be times when the user needs to run
the Finder in addition to their shell program.


- -Paul Wenker
- -Apple Computer

+++++++++++++++++++++++++++

From: [e-mail] (Levent Mollamustafaoglu)
Date: 26 Jun 92 19:16:17 GMT
Organization: Aiken Computation Lab, Harvard University

In article <[e-mail]> [e-mail] (Paul Wenker) writes:
>
>Here are some things to keep in mind when sending events to the Finder.
>
>1) Be sure you can handle the case where the Finder isn't running.  There
>are cases now (and there will be more in the future) where the Finder gets
>replaced by another shell program.
>

Another case to consider is when there is no shell and no Finder running.
(Just add the Quit command to the Finder, launch other applications, then
quit from the Finder) It seems the best way is to send the event to the
Finder and deal with errors when you can not get a result. Using the
process manager is also a good idea, but I would prefer to rely on the
events themselves, instead of the Process Manager, which might change.

Thanks for all the help.


===========================================================================
Dr. Levent Mollamustafaoglu       Harvard University
[e-mail]    [e-mail]
===========================================================================

---------------------------

From: [e-mail] (Samuel Cederlund)
Subject: Light-weight processes in a Mac program
Date: 21 Jun 92 16:34:28 GMT
Organization: Royal Institute of Technology, Stockholm, Sweden



I'm writing a package for light-weight processes on the mac. The code is pretty
straightforward. Stacks are allocated off a global array, ie

unsigned char    stacks[0x4000];

I'm using MPW 3.2 and Macsbug in 7.0.
Changing the stack pointer seems to break the system, however. I have managed to
run the program as an MPW tool by changing to user mode in the debugger.

I understand changing the stack pointer into some heap-allocated block would
cause an error like "stack has grown into heap" or something similar. But global
variable space?
  Now, if there be a compelling reason why the SP must be in the stack area, then
a solution would be simply to *grow* the stack area. Can this be done?


I'd gratefully appreciate any comments on the above from anybody with greater
insights than myself (5 000 000 000, although I hope not all of them read this
newsgroup :-)).

    Sam

Samuel Cederlund        | "When a true genius appears in the world,
programming Mac         |  it is the sign that the dunces are all in
[e-mail]        |  confederacy against him."

+++++++++++++++++++++++++++

From: [e-mail] (Tim Hammett)
Date: 21 Jun 92 21:46:47 GMT
Organization: University of Auckland, New Zealand.

[e-mail] (Samuel Cederlund) writes:
>I'm writing a package for light-weight processes on the mac. The code is pretty
>straightforward. Stacks are allocated off a global array, ie

>unsigned char    stacks[0x4000];

>I'm using MPW 3.2 and Macsbug in 7.0.
>Changing the stack pointer seems to break the system, however. I have managed t
>run the program as an MPW tool by changing to user mode in the debugger.

There are two problems with implementing threading by changing your stack
pointer. First, as you have mentioned, if you put your stacks in the
heap, a "stack has collided with heap" system error will probably
occur. Second, some Toolbox/OS/System (not sure which) routines treat
the space between A7 & the top of the heap as scratch space. This eliminates
the avenue of allocating your threads' stacks on the stack.

This leaves the option of implementing your threading routines by
stack copying. A package which does this (although source is not
available) can be found in Apple's develop magazine, issue 6 (with additional
info in issue 7), and on the developer CD's. There is also some (non-Mac
specific information on threading in the AT&T C++ documentation that comes
with MPW C++.

- --
Tim Hammett, Botany Dept, Auckland University, New Zealand.
[e-mail]   Phone: [phone] x8365    FAX: [phone]

---------------------------

From: [e-mail] (Stephen L Chamberlin)
Subject: need help writing a screensaver
Date: 21 Jun 92 20:37:51 GMT
Organization: Massachusetts Institute of Technology

I'm just getting started trying to write a simple screensaver which runs as a
background application with System 7, and I'm having trouble figuring out how
to black out the screen. There doesn't seem to be any obvious way of turning
the whole screen black from a background app. The only solutions I've come up
with so far are:

1. Create a new GrafPort the size of the main screen and paint it black. This
doesn't work very well because the finder still redraws the icons for mounted
drives on top of my nice new GrafPort, and certain other things like flashing
cursors seem to poke through as well.

2. Create a new, borderless window the size of the screen and paint it black.
This works great as long as my screensaver app is the current app, but if it's
in the background, the black window appears BEHIND the windows of the current
app, which makes it pretty useless as a screensaver. Calls to SelectWindow()
and BringToFront() don't seem to work. Apparently something prevents an
application running in the background from making one of its windows the
front window.

Any great ideas? I'm wondering how screensavers such as After Dark black out
the screen. Any ideas or input on this topic would be appreciated. Thanks!

Steve Chamberlin - [e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Steve G. Crutchfield)
Organization: Case Western Reserve University, Cleveland, Ohio, (USA)
Date: Mon, 22 Jun 92 05:42:29 GMT


The first method you mentioned is, I think, the best way to go
about it.  You can prevent other applications from drawing over
your port by setting the global variable grayRgn to an empty
region (of course you have to save it so you can restore it
later).  Then, use the obscure Window Manager routine
CalcVisBehind, passing it a pointer to the frontmost window,
and the OLD grayRgn.  This makes sure the window manager knows
that no drawing can take place in any windows.

You can also prevent things like SuperClock from appearing by
setting the global variable mBarHeight to 0.  (You have to
reset this one too, of course!)

Hope this helps.

Steve Crutchfield
[e-mail]


---------------------------

From: [e-mail] (Josh Adams)
Subject: Offscreen PixMaps
Date: 12 Jun 92 12:31:16 GMT
Organization: Extended Bulletin Board Service

What is the easiest way to have offscreen PixMaps? (yes, I thought awhile
ago  when I was asking about type-casting PixMaps that I was doing it,
but I was wrong...)  Anyway, I've heard something about gWorlds, but have
not seen anything about them. I don't think they're in IM V, but they are in
VI, which I don't have. If someone could tell me how to do offscreen PixMaps
easily, I'd be very grateful...

Thanks...
Josh

- --
   The opinions expressed are not necessarily those of the University of
     North Carolina at Chapel Hill, the Campus Office for Information
        Technology, or the Experimental Bulletin Board Service.
           internet:  bbs.oit.unc.edu or 152.2.22.80

+++++++++++++++++++++++++++

From: [e-mail] (Joe Zobkiw)
Date: 12 Jun 92 12:45:11 GMT
Organization: The World Public Access UNIX, Brookline, MA

To learn about offscreen pixmaps or bitmaps, read the technical note about
them. I forget the number off the top of my head but 120 seems to stick
in my mind. There are two notes, one on bitmaps, one of pixmaps. The code
included in the notes is ALL YOU NEED to make it work.






- --
- -- joe zobkiw                      Internet: [e-mail]
- --                                      AOL: AFL Zobkiw
- -- mac.synthesis.MIDI.THINK C.OOP.asm   CI$: 70712,515
- -- communications.networks.cool tunes...

+++++++++++++++++++++++++++

From: [e-mail] (Vince Vann)
Organization: University of Miami Medical School
Date: Fri, 12 Jun 1992 18:22:02 GMT

[e-mail] (Josh Adams) writes:
: What is the easiest way to have offscreen PixMaps? (yes, I thought awhile
: ago  when I was asking about type-casting PixMaps that I was doing it,
: but I was wrong...)  Anyway, I've heard something about gWorlds, but have
: not seen anything about them. I don't think they're in IM V, but they are in
: VI, which I don't have. If someone could tell me how to do offscreen PixMaps
: easily, I'd be very grateful...
:

First, you should read the macintosh technical note #120 entitled
"Principia Offscreen Graphics Environments".  This covers everything you
need to know about PixMaps, CGrafPorts, and GDevices, plus some info on
32-Bit QuickDraw GWorlds.

Second, if you are using THINK C 5.02 and TCL, I have written two TCL
classes that handle everything needed to setup an offscreen color graphics
environment.  If you are interested in these classes (CPixelWorld and
CPixelWorldPane), please contact me via E-mail and I will send you the
source.

Note: I am currently revising the PixelWorld classes. As soon as I complete
the revisions, I will submit the source to the <ftp.brown.edu> archive.
I'll post a message to C.S.M.P as soon as they are available.

Good luck,
Vince

- --
Vincent R. Vann
University of Miami
School of Medicine
Miami, FL

E-mail:  [e-mail]

+++++++++++++++++++++++++++

From: [e-mail]!gluttony.reed.edu!pcalahan (Patrick John Calahan)
Date: 16 Jun 92 19:56:17 GMT
Organization: Reed College, Portland, OR


I want to do drawings in offscreen pixmaps.  I set everything up
with NewPixMap(), and for the most part it works ok.
BUT

If I copybits to the pixmap and then to the screen, all non-white pixels
are drawn on the screen in black.  However, If I copybits the image
directly to the screen, it looks fine.  This suggests to me that I am
setting one of the pixmap's fields incorrectly. (?)

Can anyone send me some code which shows how to do this correctly?
Mail to [e-mail] or post here...

Thanx in advance,
    Pat

+++++++++++++++++++++++++++

From: [e-mail] (Jeremiah Blatz)
Date: 24 Jun 92 05:23:45 GMT
Organization: Dartmouth College, Hanover, NH

In article <[e-mail]>
[e-mail]!gluttony.reed.edu!pcalahan (Patrick John Calahan)
writes:

> If I copybits to the pixmap and then to the screen, all non-white pixels
> are drawn on the screen in black.  However, If I copybits the image
> directly to the screen, it looks fine.  This suggests to me that I am
> setting one of the pixmap's fields incorrectly. (?)

You could be setting thr "mode" field incorrectly, probably one of the
"or" methods (srcOr (1) or notSrcOr (5)). For a standard copy, the
transfer method is srcCopy (0).

Hope this helps,
Jeremiah
     _______________________________.
    /___  . _____. ___  __  ___  . /
       / / /____/ /__/ / / /__) / /
__    / / _____/   ___/ / ___  / /
\ \__/ / /____/ /\ \   / /__) / /___
 \____/______/ /  \_\ /______/_____/
[e-mail]

"When the world is running down, you make the best of what's still
around."
                         -Sting

---------------------------

From: [e-mail] (Richard Kennaway)
Subject: Apple Event problem
Date: 12 Jun 92 22:00:25 GMT

I recently upgraded an application to use Apple Events.  Just the required
set, i.e. open appl, open doc, print doc, and quit.  I'm not very happy
with the result.

It's a text editor.  Suppose I open it by double-clicking on a document it
created, and then search for a string in that document.  So I go, without
a pause, click-click, command-F (to bring up its search dialog), type
string, return.  Previously, this would work.  It would open the doc via
GetAppFiles, then start processing events and find my keystrokes waiting
for it.  With Apple Events, however, I find that WaitNextEvent delivers my
keystrokes before the Apple Event telling it to open a document.  This is
not good - I want to search for the string after the document is open.  I
have to wait until the window appears before I can do anything, and for no
good reason.  (BTW, contrary to the example program and recommendations
way back in IM vol.1, I never call FlushEvents at startup, and for the
same reason.  It imposes an unnecessary wait on the user.  And besides,
dammit, when I type, the machine should listen!)

I tried giving AppleEvents priority, by doing a WaitNextEvent(
highLevelMask, ... ) and only if that returned false doing WaitNextEvent(
everyEvent, ... ).  It solved the problem but created worse ones.  I got
various unpleasant weirdness: losing some osEvts, behaving as if
getFrontClicks was on, which it wasn't, etc.,

Since it currently has no use for any other Apple Events, I could just set
it back to non-Sys7-aware, but I may want to do more exotic things with
Apple Events in future.

Is there a solution?

BTW, what is the purpose of the "open application" Apple Event?  Informing
an application that it is open seems remarkably superfluous.  Cogito ergo
sum - if the app is in a position to wonder if it's running, it is.

- --
Richard Kennaway     SYS, University of East Anglia, Norwich NR4 7TJ, U.K.
Internet:  [e-mail]               uucp:  ...mcsun!ukc!uea-sys!jrk

+++++++++++++++++++++++++++

From: [e-mail] (Jack Littleton)
Date: Sat, 13 Jun 1992 18:09:17 GMT
Organization: Apple Computer, Inc.

In article <[e-mail]>, [e-mail] (Richard Kennaway) writes:
> BTW, what is the purpose of the "open application" Apple Event?  Informing
> an application that it is open seems remarkably superfluous.  Cogito ergo
> sum - if the app is in a position to wonder if it's running, it is.

I know this isn't the answer you were looking for (i.e. how to handle events
after immediately opening your document -- sounds tough), but anyway...

Only the Finder uses the open application event, and it is indeed sent after
the application has been opened.  What it is supplied for is for
initialization code such as bringing up a empty, untitled window.  It's
simply a signal that your application was opened by the Finder.

- --
Jack Littleton
Developer Tools Engineering Group
Apple Computer, Inc.


+++++++++++++++++++++++++++

From: [e-mail] (J. S. Greenfield)
Date: 13 Jun 92 21:17:45 GMT
Organization: Syracuse University, CIS Dept.

In article <[e-mail]> [e-mail] (Richard Kennaway) writes:
>I recently upgraded an application to use Apple Events.  Just the required
>set, i.e. open appl, open doc, print doc, and quit.  I'm not very happy
>with the result.

[...]

>I tried giving AppleEvents priority, by doing a WaitNextEvent(
>highLevelMask, ... ) and only if that returned false doing WaitNextEvent(
>everyEvent, ... ).  It solved the problem but created worse ones.  I got
>various unpleasant weirdness: losing some osEvts, behaving as if
>getFrontClicks was on, which it wasn't, etc.,

[...]

>Is there a solution?
>
>BTW, what is the purpose of the "open application" Apple Event?  Informing
>an application that it is open seems remarkably superfluous.  Cogito ergo
>sum - if the app is in a position to wonder if it's running, it is.

I'd say it's there for a very good reason--and it is very much related to
the solution to your problem.  Because of the "open application" event,
you know that no materr *how* your (apple-event aware) application is started,
you will *always* receive an initial apple event after startup (either an
'oapp', an 'odoc', or a 'pdoc' event).

Because of this, you can program your application to await *only* high-level
events *until* the initial apple event arrives.  (You shouldn't stop looking
for apple events just because the first call to WaitNextEvent with the
high-level event mask comes up with a null event.)

So set your program to wait for the initial apple event, process it, and then
process any other events that are waiting.  That should make things work the
way you want.


- --
J. S. Greenfield                                         [e-mail]
(I like to put 'greeny' here,
but my d*mn system wants a
*real* name!)                        "What's the difference between an orange?"

+++++++++++++++++++++++++++

From: [e-mail] (Grobbins)
Date: 14 Jun 92 09:38:57 GMT
Organization: DTS, more or less

In article <[e-mail]> [e-mail] writes:
>Because of the "open application" event,
>you know that no materr *how* your (apple-event aware) application is started,
>you will *always* receive an initial apple event after startup (either an
>'oapp', an 'odoc', or a 'pdoc' event).

While this is presently true under normal circumstances, application
code should still be written defensively: do not demand an Apple
event after starting up, and do not depend on receiving one of those three.

>Because of this, you can program your application to await *only* high-level
>events *until* the initial apple event arrives.  (You shouldn't stop looking
>for apple events just because the first call to WaitNextEvent with the
>high-level event mask comes up with a null event.)
>
>So set your program to wait for the initial apple event, process it, and then
>process any other events that are waiting.  That should make things work the
>way you want.

It is not a good idea to mask out everything.  Always handle update
events when they come in, and do remember that OS events are not
queued, so if you are keeping track of being in the foreground or
background by looking at suspend/resume events, then OS events should
never be masked out.

There is a way to "prefetch" Apple events via the GetSpecificHighLevelEvent
call, but it's rather ugly and probably best avoided.  See the Event Manager
chapter of Inside Mac VI for documentation on this stuff.

Grobbins          [e-mail]

Usual disclaimers apply.


+++++++++++++++++++++++++++

From: [e-mail] (Jon Pugh)
Date: 15 Jun 92 05:44:59 GMT
Organization: Apple Computer, Inc.

In article <[e-mail]>, [e-mail] (Jack Littleton) writes:
>
> In article <[e-mail]>, [e-mail] (Richard Kennaway) writes:
> > BTW, what is the purpose of the "open application" Apple Event?  Informing
> > an application that it is open seems remarkably superfluous.  Cogito ergo
> > sum - if the app is in a position to wonder if it's running, it is.
>
> I know this isn't the answer you were looking for (i.e. how to handle events
> after immediately opening your document -- sounds tough), but anyway...
>
> Only the Finder uses the open application event, and it is indeed sent after
> the application has been opened.  What it is supplied for is for
> initialization code such as bringing up a empty, untitled window.  It's
> simply a signal that your application was opened by the Finder.

I would like to add that if you launch and don't get an Open Application
event, you should just go straight to your event loop without any fuss.
This may be done to get you to launch in the background, like a daemon for
example. This way you won't bother the user of the machine, who won't be
looking for you, since you would've gotten an oapp, odoc or pdoc if he was
looking at your program.

Once again, no oapp, no new doc. Just go to the main event loop after
initializing everything. You should be ready to do a new doc or whatever.

Jon Pugh
kAERegistrar

+++++++++++++++++++++++++++

From: [e-mail] (Brady Michael)
Organization: Trinity College, Dublin (Computer Science)
Date: Mon, 15 Jun 1992 09:43:25 GMT

In article <[e-mail]> [e-mail] (Grobbins) writes:
>
>While this is presently true under normal circumstances, application
>code should still be written defensively: do not demand an Apple
>event after starting up, and do not depend on receiving one of those three.

I'm looking for a little clarification on this:
The way I have set up my application - Open Prolog - is this: after it starts up
it looks for a pending high-level event, of type OAPP, ODOC or PDOC. If
none of these are present, somewhere in the event queue, then the
application presumes that it has been started in a non-HLE environment
and goes on to getAppFiles, etc.
Are you saying this is inadvisable?

Mike
- --
Michael Brady                         [e-mail]
Department of Computer Science
University of Dublin, Trinity College Dublin, Ireland


+++++++++++++++++++++++++++

From: [e-mail] (Scott Storkel)
Organization: Oracle Corporation, Belmont, CA
Date: Mon, 15 Jun 1992 18:12:47 GMT


In article <[e-mail]> [e-mail] (Brady Michael) writes:

>I'm looking for a little clarification on this:
>The way I have set up my application - Open Prolog - is this: after it starts up
>it looks for a pending high-level event, of type OAPP, ODOC or PDOC. If
>none of these are present, somewhere in the event queue, then the
>application presumes that it has been started in a non-HLE environment
>and goes on to getAppFiles, etc.
>Are you saying this is inadvisable?

Okay, here's what I'd do. I think this is correct, but somebody from Apple
can point me down the right path if I've strayed...

1. Initialize everything. This includes all of the Toolbox managers as well
   as application initialization code.

2. Call Gestalt and see if the Apple Event Manager is present. If yes, goto 4.

3. AE Manager isn't available, so open/print files using CountAppFiles(),
   GetAppFiles(), etc. Create an "untitled" document if you would normally
   do so in response to an oapp Apple Event.

4. Enter your main event loop! Be sure to handle the oapp, odoc, and pdoc
   Apple Events. If you get odoc or pdoc events, open or print the
   corresponding files. If you get an oapp event, open an "untitled" document
   or perform any other user visible actions that should happen when your
   program is launched.

It's important to note that #4 should be your real, live, handle-everything
main event-loop. Any questions?


                                -- Scott


==============================================================================
Code Warrior                    500 Oracle Parkway
Advanced Products Division            Box 659405
Oracle Corporation                Redwood Shores, CA. 94065
415-506-2493                    FAX: [phone]
==============================================================================
- --

==============================================================================
Code Warrior                    500 Oracle Parkway
Advanced Products Division            Box 659405
Oracle Corporation                Redwood Shores, CA. 94065
415-506-2493                    FAX: [phone]
==============================================================================

+++++++++++++++++++++++++++

From: [e-mail] (Earl Baugh)
Date: 16 Jun 92 20:34:38 GMT
Organization: ISX Corporation, East Coast Office

In article <[e-mail]> [e-mail] (Jack Littleton) writes:
>In article <[e-mail]>, [e-mail] (Richard Kennaway) writes:
>> BTW, what is the purpose of the "open application" Apple Event?  Informing
>> an application that it is open seems remarkably superfluous.  Cogito ergo
>> sum - if the app is in a position to wonder if it's running, it is.
>
>Only the Finder uses the open application event, and it is indeed sent after
>the application has been opened.

    Sorry to say, that's not the only way an application gets an Open
Application Event.  Any application that uses LaunchApplication to launch
your application can cause it to get an Open Application event.   (We
won't discuss how badly the LaunchApplication call is documented.....)
BTW, your application can get just about any event from the Launching program,
open document comes to mind...

'later

- --
    Earl D. Baugh Jr.
    ISX Corporation
    Internet : [e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Jon Pugh)
Date: 26 Jun 92 04:35:46 GMT
Organization: Apple Computer, Inc.

In article <[e-mail]>, [e-mail] (Brady Michael) writes:
>
> The way I have set up my application - Open Prolog - is this: after it starts up
> it looks for a pending high-level event, of type OAPP, ODOC or PDOC. If
> none of these are present, somewhere in the event queue, then the
> application presumes that it has been started in a non-HLE environment
> and goes on to getAppFiles, etc.
> Are you saying this is inadvisable?

Yes, this is inadvisable.

Call Gestalt and see if the AE manager is available.  If you have the SIZE
resource's highLevelEventAware bit then you will get an AE and you can just
relax, initialize and idle, dealing with whatever you get or don't get when
you do or don't get it, as you should.

If the AEM is not available, check the appFiles.

Jon
kAERegistrar


---------------------------

From: [e-mail] (Jason Philip Stevens)
Subject: Getting the text from a TERec
Date: 15 Jun 1992 17:46:56 GMT
Organization: Baylor College of Medicine, Houston, Tx


I'm trying to extract the text from a TERec into a standard C-style
char* .  Suppose I have a TERec**, TEHandle.

Accoring to IM-1, p377, the hText member is a "handle to the text to
be edited."  if I try *(*TEHandle)->hText, I get garbage.  If I try to
use the TEGetText routine, I get a CharsHandle returned (a handle to a
packed array of chars).  If I dereference that, I also get garbage.
How do I actually get my hands on a char*?

BTW, I've tried using PtoCstr, on the assumption that the resultant string
would be in Pascal format, and while it compiles, in use it generates a
bus error...

Thanks for any help...

- -jps
- --
Jason Stevens            Internet:  [e-mail]
Network User Services        Voice:  [phone]
Baylor College of Medicine    Opinions expressed are mine alone.


+++++++++++++++++++++++++++

From: [e-mail] (Joe Zobkiw)
Organization: The World Public Access UNIX, Brookline, MA
Date: Tue, 16 Jun 1992 01:03:28 GMT

In article <[e-mail]> [e-mail] (Jason Philip Stevens) writes:
>
>I'm trying to extract the text from a TERec into a standard C-style
>char* .  Suppose I have a TERec**, TEHandle.
>

Well, first of all, if your TERec contains more than 255 characters of text
you may bomb when you try to cast it as a Str255. However, if you want to do
this you can use something like:

void TE2Str(TEHandle te, Str255 str)
{
    GetIText((te)->hText, str);
}

void Str2TE(Str255 str, TEHandle te)
{
    TESetText((Ptr)&str[1], (long)str[0], te);
}

This might also help you with your other problem, finding the text.
Remember, hText is a _Handle_ to the text in question. Two dereferences
of a Handle get you to it's data.


- --
- -- joe zobkiw                      Internet: [e-mail]
- --                                      AOL: AFL Zobkiw
- -- mac.synthesis.MIDI.THINK C.OOP
- -- asm.comm.networks.cool tunes...

+++++++++++++++++++++++++++

From: [e-mail] (Humayun Lari)
Date: 16 Jun 92 18:12:33 GMT
Organization: University of North Carolina, Chapel Hill

In article <[e-mail]> [e-mail] (Joe Zobkiw) writes:
>In article <[e-mail]> [e-mail] (Jason Philip Stevens) writes:
>>
>>I'm trying to extract the text from a TERec into a standard C-style
>>char* .  Suppose I have a TERec**, TEHandle.
>>
>
>Well, first of all, if your TERec contains more than 255 characters of text
>you may bomb when you try to cast it as a Str255. However, if you want to do
>this you can use something like:
>
>void TE2Str(TEHandle te, Str255 str)
>{
>    GetIText((te)->hText, str);
>}

Um, isn't GetIText only for dialogs? Perhaps this might be a bit better:

OSErr TE2CStr(TEHandle te, char *str)
{
    short  textLength;

    textLength = (**te).teLength;
    str = (char *)NewPtr(textLength + 1);
    if (MemError() != noErr)
        return MemError();

    BlockMove( (Ptr)(*TEGetText(te)), (Ptr)str, textLength);
    str[textLength] = '\0';

    return noErr;
}

Since you're using C, this should work OK no matter how much text the TERec
contains (up to the 32K limit). Anyone see a silly mistake? (My C's kind of
rusty.)

>
>void Str2TE(Str255 str, TEHandle te)
>{
>    TESetText((Ptr)&str[1], (long)str[0], te);
>}

void CStr2TE(char *str, TEHandle te)
{
    TESetText((Ptr)str, strlen(str), te);
}

>
>This might also help you with your other problem, finding the text.
>Remember, hText is a _Handle_ to the text in question. Two dereferences
>of a Handle get you to it's data.

After years and years, I still forget... :-)


Humayun Lari
([e-mail])

+++++++++++++++++++++++++++

From: [e-mail] (Elizabeth Wylie)
Date: 17 Jun 92 04:26:05 GMT
Organization: U.C. Berkeley Open Computing Facility

> >void TE2Str(TEHandle te, Str255 str) >{ > GetIText((te)->hText,
> str); >}
>
> Um, isn't GetIText only for dialogs? Perhaps this might be a bit
> better:

I noticed the GetIText call as well, but thought about it and had to smile.

":-)"

When you perform a GetDItem on an edit text in a dialog, you get a handle to
the text of the item.  GetIText just copies at most 255 bytes of this handle
into a pascal string.  So long as it is passed a handle to text, you're OK.

vrey nice.
- -Elizabeth

+++++++++++++++++++++++++++

From: [e-mail] (Joe Zobkiw)
Date: 17 Jun 92 10:46:38 GMT
Organization: The World Public Access UNIX, Brookline, MA

The GetIText 'trick' came from THINK Reference. I will not take credit
for it. I just found it to be an easy to understand way of doing things :)


- --
- -- joe zobkiw                      Internet: [e-mail]
- --                                      AOL: AFL Zobkiw
- -- mac.synthesis.MIDI.THINK C.OOP
- -- asm.comm.networks.cool tunes...

+++++++++++++++++++++++++++

Date: 24 Jun 92 19:33:49 GMT
From: [e-mail] (Jorma Paananen)

[e-mail] (Humayun Lari) writes:
> void CStr2TE(char *str, TEHandle te)
> {
>     TESetText((Ptr)str, strlen(str), te);
> }

>From IM I-383:
  "TESetText doesn't dispose of any text currently in the edit record"

What is the correct way to free old text ?

Jorma
[e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Humayun Lari)
Date: 25 Jun 92 20:52:29 GMT
Organization: University of North Carolina, Chapel Hill

In article <[e-mail]> [e-mail] (Jorma Paananen) writes:
>[e-mail] (Humayun Lari) writes:
>> void CStr2TE(char *str, TEHandle te)
>> {
>>     TESetText((Ptr)str, strlen(str), te);
>> }
>
>From IM I-383:
>  "TESetText doesn't dispose of any text currently in the edit record"
>
>What is the correct way to free old text ?


Well, I *did* have a feeling that it couldn't be that simple :-).
Maybe this will work: (Anyone see more amazingly silly mistakes?)

void CStr2TE(char *str, TEHandle te)
{
     TESetSelect(0, 32767, te);   /* IM I-385 */
     TEDelete(te);                /* IM I-387 */
     TESetText((Ptr)str, strlen(str), te);
}

Note that the edit record should be inactive, or else the selection will be
highlighted. If the string is long, you might prefer to use TEGetText to access
the text handle directly, so you can check for memory errors when resizing the
handle to fit.

Humayun Lari
([e-mail])
ObSig: "Technology changes rapidly; people and meaning do not." -- Kevin Bjorke

---------------------------

End of C.S.M.P. Digest
**********************